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REMARKS 

Reconsideration of the rejection set forth in the Office Action is respectfully requested. 
By this Amendment, claims 1-5, 7, 9-14, 16, 18-22, and 26-28 have been amended. Currently, 
claims 1-28 are pending in this application. 

gpj pctinn claims 1 -9.8 under 35 USC 102 over Ahem 

Claims 1-28 were rejected under 35 USC 102 as anticipated by Ahem (U.S. Patent No. 
5,926,463). This rejection is respectfully traversed in view of the amendments to the claims and 

the following arguments. 

Multicast trees are commonly established to distribute information to multicast 
participants in an efficient manner. As noted in the background of the invention, there are 
several routing protocols that may be used to establish a multicast tree, two of which are Protocol 
Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP). (See 
Specification at page 2, lines 4-6). A particular application wilt generally use only one of these 
multicast routing protocols. 

Once a multicast tree has been established using one of these routing protocols, the 
multicast tree may be used by the application that established the multicast tree, and may be read 
by other applications that are configured to use the same routing protocol that was used to 
establish the multicast tree. (Specification at page 2, lines 8-9). However, applications that are 
configured to read multicast information established using a particular multicast routing protocol 
have conventionally not been able to read information about multicast trees using a routing 
protocol other than that particular multicast routing protocol. For example, a network 
management application configured to troubleshoot DVMRP trees by reading DVMRP multicast 
routing information would not be able to use a multicast tree established using PIM. (See e.g. 
specification at page 2, lines 9-11). Examples of several applications that may wish to read 
previously established multicast tree information include network management programs and 
other programs that may wish to route data or troubleshoot multicast problems. (Specification at 
page 1, line 28 to page 2, line 2; and at page 8, lines 25-27). 

Applicant discovered that multicast information could be stored in a Management 
Information Base (MIB) on routers on the network in a protocol neutral format and then 
retrieved by applications using an available network management protocol, such as Simple 
Network Management Protocol (SNMP), by applications using different types of multicast 
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protocols. Further, applicant discovered that the retrieved information could be processed by the 
applications to enable the applications to recreate the established multicast tree in a protocol 
specific fashion to enable the application to use the multicast tree on the network. 

The Examiner has taken the position that Ahem discloses a method of producing a 
multicast tree from existing multicast information, or a multicast in a network which includes 
storing multicasting information in a protocol independent manner in network devices. 
Applicant respectfully disagrees with this interpretation of Ahem. Rather, applicant respectfully 
submits that, as discussed in greater detail below, Ahem discloses a network management system 
that is configured to trace DVMRP trees through the network. (See e.g. Ahem at col. 13, lines 
37-40). Since the application is configured to collect DVMRP information from the routers on 
the network, the information being stored in the network elements is not protocol independent 
but rather is standard DVMRP multicast routing information.. 

The Examiner has cited Figs. 3, 8 (items 9A, 9) the Abstract, Col. 6, line 55 to Col. 7, 
line 17 (MB H) and Col 17, lines 34-57, of Ahem as support for the Examiner's position that 
Ahem teaches storing multicast routing information on the routers m a protocol neutral format. 
Applicants respectfully submit that none of these portions of Ahem teach or suggest that the 
routers should implement a protocol independent multicast database containing protocol 
independent multicast routing information. Each of the cited aspects of Ahem are discussed 
below. 
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The Examiner cited Fig. 3 of Ahem, 
reproduced below: 



For convenience, Fig. 3 of Ahem has been 
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Fig. 3 



From an initial review it appears that Figure 3 of Ahem shows a screen shot of a management 
program that is configured to display the network elements in a network topology. Elements 9 
and 9A in Fig. 3 show routers or other types of network devices but do not show that the routers 
should contain a multicast database that is protocol independent. 

Fig. 3 is described in the description of the figures section, for example at col. 4, line 63, 
as a multimedia path tracing view of the network. Fig. 3 is discussed in greater detail at col. 6, 
line 55 to col. 7, line 17, which was also cited by the Examiner as support for teaching the use of 
a protocol independent multicast database. This portion of Ahem describes in a general way 
how routers may subscribe to a multicast by transmitting requests to join an existing multicast up 
toward the source until the tree is found. This portion of Ahem also teaches that the network 
supervisor may analyze the individual links in the multicast tree and the individual devices on 
the multicast tree. Ahem does not mention that the devices on the tree should store the multicast 
information in a protocol independent manner in this cited portion. 
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The Examiner also cited Fig. 8 of Ahem, which is reproduced below for convenience: 




1 . Collision Domain. Bus topology of A nodes 

2. Network Switch, connecting collision domain to routed petwora 

3. Layar 2, FDDl dual ring topology 



Fig. 8 



This figure, like Figure 3, appears to be a screen snapshot of a network management program, 
illustrating various network elements interconnected in a particular network topology. At col. 5, 
lines 4-5 of Ahem, this figure is described as a routing overview of the network which can be 
expanded to show information from the other views. Fig. 8 is described in greater detail at Col. 
5, line 39 to Col. 6, line 23. In this portion of the description, Ahem describes the different 
network elements that are connected together by the links shown in the figure and generally 
describes the network topography shown in Fig. 8. Ahem also mentions that the network 
manager may zoom in on particular links and network elements using the user interface shown in 
Fig. 8. However, Ahem does not teach or suggest in this part of the written description that any 
of the network elements shown in Fig. 8 should include a protocol independent multicast 
database. 

The last portion of Ahem that the Examiner cited as teaching a protocol independent 
multicast database is Col. 17, lines 34-57 (MIB D). This portion of Ahem falls under the 
heading MRTREE (See Col. 15, line 22) and, accordingly, is to be read in the context of this 
section of Ahern. 

MRTREE is a public domain application (Abem at Col. 1.7, lines 37-38) that is 
configured to access the DVMRP MIB to obtain information about potential multicast trees. 

-11- 
PAGE 15117 1 RCVDAT 1/2312006 5:04:27 PM [Eastern Standard Time]' SVR:USPT0tf XRF-6/29 ' DNISOTO' CSID: 197837132 19 » DURATION (mm-ss) :05-30 



01/23/2006 17:11 19783713219 



JOHN C GORECKI 



PAGE 16/17 



Amendment Dated January 23, 2006 
Serial No. 09/842,604 

(Ahem at Col. 15, lines 45-49). The MRTREE application uses IGMP and SNMP queries to 
discover multicast tree information on the network. As is well known, IGMP is a protocol that 
enables entities to join and leave multicast* on an P network, but is not a multicast routing 
protocol Rather, IGMP is used to gain membership in a multicast, but does not actually carry 
any user data. A routing protocol such as DVMRP is used to organize routers into a tree, and the 
potential tree information is stored in the DVMRP M1B (See Ahem at Col. 15, lines 45-48). The 

IGMP and SNMP queries thus are used to retrieve the DVMRP information from the router* for 

use by the DVMRP implemented MRTREE application. 

The portion of Ahem cited by the Examiner (Col 17, lines 34-57) discusses the Mffi 

objects that are required on the network elements to support the MRTREE application. Of me 13 

identified MIB objects, 7 arc DVMRP specific: 

• DVMRP version; 

• DVMRP virtual interface local address; 

• DVMRP virtual interface remote address; 

• DVMRP virtual interface remote subnet mask; 

• DVMRP neighbor version; 

• DVMRP Route upstream neighbor; and 

• DVMRP Route Next Hop Type 

dearly the MIB required to implement Ahern's solution requires DVMRP multicast routing 
information to be stored in the network elements. Thus, Ahem does not teach or suggest storing 
protocol independent multicast routing information on the routers. 

Applicants have amended the claims to clarify that the protocol independent multicast 
database contains protocol independent multicast routing information. In view of the 
amendments to the claims and the fact that Ahem uses a DVMRP specific application to trace 
multicast information on network devices, applicants respectfully request that the rejection of the 
claims be withdrawn. 



Conclusion 

Applicants respectfully submit that the claims pending in this application are in condition 
for allowance and respectfully request an action to that effect. If the Examiner believes a 
telephone interview would further prosecution of this application, the Examiner is respectfully 
requested to contact the undersigned at the number indicated below. 
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If any fee 5 arc due in connection with this filing, the Commissioner is hereby authorized 
to charge payment of the fee, associated with this communication or credit any overpayment to 
Deposit Account No. 502246 (Ref. NN-13774). 

Respectfully Submitted 



Dated: January 23, 2006 



John C. Gorecki, Esq. 
P.O. Box 553 
Carlisle, MA 01 741 
Tel: (978) 371-3218 
Fax:(978)371-3219 
john@goredri.us 




Jotth C Gorecki 
Registration No. 38,471 
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